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Abstract  --  Reuse  of  large-grain  software  components  offers 
the  potential  for  significant  savings  in  application  development 
cost  and  time.  Successful  reuse  of  components  and  component 
substitutability  depends  both  on  qualities  of  the  components 
reused  as  well  as  the  software  context  in  which  the  reuse  is 
attempted.  Disciplined  approaches  to  the  structure  and  design 
of  software  applications  offers  the  potential  of  providing  a  hos¬ 
pitable  setting  for  such  reuse.  We  present  the  results  of  a  series 
of  exercises  designed  to  determine  how  well  “off-the-shelf” 
constraint  solvers  could  be  reused  in  applications  designed  in 
accordance  with  the  C2  software  architectural  style.  The  exer¬ 
cises  involved  the  reuse  of  SkyBlue  and  Amulet’s  one-way  for¬ 
mula  constraint  solver.  We  constructed  numerous  variations  of 
a  single  application  (thus  an  application  family).  The  paper 
summarizes  the  style  and  presents  the  results  from  the  exer¬ 
cises.  The  exercises  were  successful  in  a  variety  of  dimensions; 
one  conclusion  is  that  the  C2  style  offers  significant  potential 
for  the  development  of  application  families  and  that  wider  tri¬ 
als  are  warranted.1 

Index  Terms  —  architectural  styles,  message-based  architec¬ 
tures,  application  families,  graphical  user  interfaces  (GUIs), 
constraint  management,  component-based  development. 

I.  Introduction 

Software  architecture  research  is  directed  at  reducing 
costs  of  developing  applications  and  increasing  the  potential 
for  commonality  between  different  members  of  a  closely 
related  product  family.  One  aspect  of  this  research  is  devel¬ 
opment  of  software  architectural  styles,  canonical  ways  of 
organizing  the  components  in  a  product  family  [10],  [27], 
Typically,  styles  reflect  and  leverage  key  properties  of  one  or 
more  application  domains  and  recurring  patterns  of  applica¬ 
tion  design  within  those  domains.  As  such,  architectural 
styles  have  the  potential  for  providing  structure  for  off-the- 
shelf  (OTS)  component  reuse. 

However,  all  styles  are  not  equally  well  equipped  to  sup¬ 
port  reuse.  If  a  style  is  too  restrictive,  it  will  exclude  the 
world  of  legacy  components.  On  the  other  hand,  if  the  set  of 
style  rules  is  too  permissive,  developers  may  be  faced  with 
all  of  the  well  documented  problems  of  reuse  in  general  [3], 
[9],  [13],  [35].  Therefore,  achieving  a  balance,  where  the 
rules  are  strong  enough  to  make  reuse  tractable  but  broad 
enough  to  enable  integration  of  OTS  components,  is  a  key 
issue  in  formulating  and  adopting  architectural  styles. 

Our  experience  with  C2,  a  component-  and  message- 
based  style  for  GUI  software  [38],  [39]  indicates  that  it  pro- 
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vides  such  a  balance.  In  a  series  of  exercises,  we  were  able 
to  integrate  several  OTS  components  of  various  granularities 
into  architectures  that  adhere  to  the  rules  of  C2.  This  paper 
focuses  on  a  subset  of  these  exercises,  in  which  we  success¬ 
fully  integrated  two  externally  developed  UI  constraint  solv¬ 
ers  into  a  C2  architecture:  SkyBlue  [32]  and  Amulet’s  one¬ 
way  formula  solver  [17].  In  doing  so,  we  were  able  to  create 
several  constraint  maintenance  components  in  the  C2  style, 
enabling  the  construction  of  a  large  family  of  applications. 
We  describe  the  details  of  these  exercises  and  the  lessons  we 
learned  in  the  process. 

The  remainder  of  the  paper  is  organized  as  follows. 
Section  II  describes  the  rules  and  intended  goals  of  C2,  as 
well  as  its  relationship  to  the  research  that  has  preceded  and 
influenced  it.  Part  of  the  material  in  this  section  is  condensed 
from  a  more  detailed  exposition  on  the  style,  given  in  [39], 
Section  III  discusses  our  approach  to  providing  implementa¬ 
tions  for  architectures  built  according  to  the  rules  of  C2. 
Section  IV  presents  a  detailed  overview  of  the  architecture 
and  implementation  of  KLAX,  the  application  used  as  the 
basis  for  our  exercises.  Section  V  motivates  the  need  for  a 
constraint  manager  in  KLAX  and  describes  the  particular 
KLAX  constraints  we  decided  to  maintain  in  an  external 
constraint  solver.  Section  VI  discusses  the  design  and  imple¬ 
mentation  issues  encountered  in  integrating  SkyBlue  and 
Amulet’s  constraint  manager  with  the  architecture.  The 
library  of  KLAX  components  created  in  the  process  of 
including  SkyBlue  and  Amulet  is  described  in  Section  VII. 
A  discussion  of  several  instances  of  the  KLAX  application 
family  built  with  the  components  from  the  library  is  given  in 
Section  VIII.  A  discussion  of  related  work  and  conclusions 
round  out  the  paper. 

II.  Overview  of  the  C2  Architectural  Style 

C2  is  an  architectural  style  designed  to  support  the  partic¬ 
ular  needs  of  applications  that  have  a  graphical  user  inter¬ 
face  aspect.  The  style  supports  a  paradigm  in  which  UI 
components,  such  as  dialogs,  structured  graphics  models  (of 
various  levels  of  abstraction),  and,  as  this  paper  will  show, 
constraint  managers,  can  more  readily  be  reused.  A  variety 
of  other  goals  are  potentially  supported  as  well.  These  goals 
include  the  ability  to  compose  systems  in  which:  compo¬ 
nents  may  be  written  in  different  programming  languages, 
components  may  be  running  in  a  distributed,  heterogeneous 
environment  without  shared  address  spaces,  architectures 
may  be  changed  dynamically,  multiple  users  may  be  inter¬ 
acting  with  the  system,  multiple  toolkits  may  be  employed, 
multiple  dialogs  may  be  active,  and  multiple  media  types 
may  be  involved. 
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II.  A.  Style  Rules 

The  C2  style  can  be  informally  summarized  as  a  network 
of  concurrent  components  hooked  together  by  connectors, 
i.e.,  message  routing  devices.  Components  and  connectors 
both  have  a  defined  top  and  bottom.  The  top  of  a  component 
may  be  connected  to  the  bottom  of  a  single  connector  and 
the  bottom  of  a  component  may  be  connected  to  the  top  of  a 
single  connector.  No  direct  component-to-component  links 
are  allowed.  There  is  no  bound  on  the  number  of  compo¬ 
nents  or  connectors  that  may  be  attached  to  a  single  connec¬ 
tor.  When  two  connectors  are  attached  to  each  other,  it  must 
be  from  the  bottom  of  one  to  the  top  of  the  other  (see  Fig.  1). 


Fig.  1 .  A  sample  C2  architecture.  Jagged  lines  represent  the  parts  of  the  ar¬ 
chitecture  not  shown. 

Each  component  has  a  top  and  bottom  domain.  The  top 
domain  specifies  the  set  of  notifications  to  which  a  compo¬ 
nent  responds,  and  the  set  of  requests  that  the  component 
emits  up  an  architecture.  The  bottom  domain  specifies  the 
set  of  notifications  that  this  component  emits  down  an  archi¬ 
tecture  and  the  set  of  requests  to  which  it  responds.  All  com¬ 
munication  between  components  is  achieved  by  exchanging 
messages.  This  requirement  is  suggested  by  the  asynchro¬ 
nous  nature  of  component-based  architectures,  and.  in  par¬ 
ticular',  of  applications  that  have  a  GET  aspect,  where  both 
users  and  the  application  perform  actions  concurrently  and 
at  arbitrary  tunes  and  where  various  components  in  the 
architecture  must  be  notified  of  those  actions.  Message- 
based  communication  is  extensively  used  in  distributed 
environments  for  which  this  architectural  style  is  suited. 

Central  to  the  architectural  style  is  a  principle  of  limited 
visibility  or  substrate  independence-,  a  component  within  the 
hierarchy  can  only  be  awar  e  of  components  “above”  it  and  is 
completely  unaware  of  components  which  reside  “beneath” 
it.  Notions  of  above  and  below  are  used  in  this  paper  to  sup¬ 
port  an  intuitive  understanding  of  the  architectural  style.  As 
is  typical  with  virtual  machine  diagrams  found  in  operating 
systems  textbooks,  hr  this  discussion  the  application  code  is 
(arbitrarily)  regarded  as  being  at  the  top  while  user  interface 
toolkits,  windowing  systems,  and  physical  devices  are  at  the 
bottom.  The  human  user  is  thus  at  die  very  bottom,  interact¬ 
ing  with  the  physical  devices  of  keyboard,  mouse,  micro¬ 
phone.  and  so  forth. 

Substrate  independence  has  a  clear  potential  for  fostering 
substitutability  and  reusability  of  components  across  archi¬ 
tectures.  One  issue  that  must  be  addressed,  however,  is  the 
apparent  dependence  of  a  given  component  on  its  “super- 


strate.”  i.e..  the  components  above  it.  If  each  component  is 
built  so  that  its  top  domain  closely  corresponds  to  the  bot¬ 
tom  domains  of  those  components  with  which  it  is  specifi¬ 
cally  intended  to  interact  in  the  given  architecture,  its 
reusability  value  is  greatly  diminished  and  it  can  only  be 
substituted  by  components  with  similarly  constrained  top 
domains.  For  that  reason,  the  C2  style  introduces  the  notion 
of  event  translation.  Domain  translation  is  a  transformation 
of  the  requests  issued  by  a  component  into  the  specific  form 
understood  by  the  recipient  of  the  request,  as  well  as  the 
transformation  of  notifications  received  by  a  component  mto 
a  form  it  understands  [39],  [43].  The  C2  design  and  develop¬ 
ment  tools  [20],  [30]  are  intended  to  provide  support  for 
accomplishing  this  task. 


Fig.  2.  The  Internal  Architecture  of  a  C2  Component. 


The  internal  architecture  of  a  component  shown  in  Fig.  2 
is  targeted  to  the  user  interface  domain.  While  issues  con¬ 
cerning  composition  of  an  architecture  are  independent  of  a 
component's  internal  structure,  for  purposes  of  exposition 
below,  this  internal  architecture  is  assumed.  C2  also  sup¬ 
ports  compositionality.  or  hierarchical  composition,  where 
an  entire  architecture  becomes  a  single  component  in 
another,  larger  architecnue. 

Each  component  may  have  its  own  thread(s)  of  control,  a 
property  also  suggested  by  the  asynchronous  nature  of  tasks 
in  the  GUI  domain.  It  simplifies  modeling  and  programming 
of  multi-component,  multi-user,  and  concurrent  applications 
and  enables  exploitation  of  distributed  platforms.  A  pro¬ 
posed  conceptual  architecture  is  distinct  from  an  implemen¬ 
tation  architecture,  so  that  it  is  indeed  possible  for 
components  to  share  threads  of  control. 

Finally,  there  is  no  assumption  of  a  shared  address  space 
among  components.  Any  premise  of  a  shared  address  space 
would  be  unreasonable  hi  an  architectural  style  that  allows 
composition  of  heterogeneous,  highly  distributed  compo¬ 
nents,  developed  in  different  languages,  with  then  own 
threads  of  control,  internal  structures,  and  domains  of  dis¬ 
course. 

II. B.  Influences 

The  C2  work  has  drawn  inspiration  from  many  soinces: 

•  layered  systems, 

•  implicit  invocation. 

•  operating  system  (OS)  process  support. 
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•  component  interoperability  models,  and 

•  softw  are  architectures. 

While  C2  has  many  similarities  to  existing  work  in  these 
areas,  there  are  also  important  differences  that  distinguish  it 
from  them. 

hi  contrast  to  existing  systems,  such  as  Field  [29]  and 
SoftBench  [6],  X  Windows  [33].  Cliiron-1  [40].  Arch  [28]. 
and  Slinky  [44],  which  support  only  a  fixed  number  of  lay¬ 
ers  in  an  architecture,  the  C2  architectural  style  allows  lay¬ 
ering  to  vary  naturally  with  the  application  domain,  hi  this, 
the  C2  style  is  similar  to  GenVoca  [2],  whose  components 
may  be  composed  in  a  number  of  layers  that  naturally 
reflects  the  characteristics  of  a  particular  domain.  Unlike 
GenVoca.  which  uses  explicit  invocation,  C2  provides  a  lay¬ 
ering  mechanism  based  oil  implicit  invocation.  This  allows 
the  C2  style  to  provide  greater  flexibility  in  achieving  sub¬ 
strate  independence  in  an  environment  of  dynamic,  multi¬ 
lingual  components:  component  recompilation  and  relinking 
can  be  avoided  and  on-the-fly  component  replacement 
enabled  [24]. 

hi  C2,  implicit  invocation  occurs  when  a  component 
invokes  its  internal  object  in  reaction  to  a  notification.  The 
invocation  is  implicit  because  a  component  issuing  notifica¬ 
tions  does  not  know  if  those  notifications  will  cause  any 
reaction,  nor  does  it  explicitly  name  an  entry  point  into  a 
component  below  it.  The  benefits  of  implicit  invocation  are 
described  in  the  context  of  mediators  by  Sullivan  and  Notkin 
[36],  [37],  While  many  systems,  such  as  Cliiron-1  and  Visu- 
alWorks  [26]2,  employ  implicit  invocation  for  its  benefits  in 
minimizing  module  interdependencies,  the  C2  style  also 
provides  a  discipline  for  ordering  components  which  use 
implicit  invocation,  yielding  substrate  independence. 

Another  example  of  implicit  invocation  is  the  Weaves 
system  [1 1],  in  which  concurrently  executing  tool  fragments 
communicate  by  passing  (pointers  to)  objects.  This  passing 
of  objects  causes  Weaves  to  be  used  in  a  data  flow  maimer. 
Weaves  allows  data  moving  between  output  and  input  por¬ 
tals  of  connected  tool  fragments.  Unlike  C2,  which  allow’s 
messages  to  flow  in  both  directions  along  a  communication 
link,  data  flow  in  w'eaves  is  unidirectional  (“left  to  right’’); 
flow"  in  the  other  direction  is  achieved  by  explicitly  creating 
communication  cycles.  Similarly  to  C2.  communication  in 
Weaves  occurs  via  connectors  (transport  services).  Further¬ 
more.  the  granularity  of  tool  fragments  is  on  the  order  of  a 
single  procedure.  This,  coupled  with  unidirectional  data 
flow"  and  communication  cycles,  can  result  in  Weave  archi¬ 
tectures  consisting  of  large  numbers  of  tool  fr  agments  and 
transport  services  with  a  complicated  interconnection  struc¬ 
ture. 

Existing  systems  tend  to  be  rigid  in  terms  of  mapping 
then  components  to  OS  processes.  At  one  extreme.  X  appli¬ 
cations  contain  exactly  two  processes,  a  client  and  a  server. 
While  there  is  greater  process  flexibility  in  VisualWorks  and 
Weaves,  both  of  these  systems  assume  a  shared  address 
space.  It  is  only  with  systems  such  as  GenVoca,  Field  or 
SoftBench.  and  C2  that  simultaneous  satisfaction  of  arbi¬ 
trary  numbers  of  processes  in  a  non-shared  address  space  is 


2.  VisualWorks  is  a  Smalltalk  GUI  library  based  on  the  Model- View-Con¬ 
troller  paradigm  [12],  where  the  model  broadcasts  change  of  state  notifica¬ 
tions  to  views  and  controllers. 


achieved. 

Existing  component  interoperability  models ,  such  as  OLE 
[5]  and  OpenDoc  [25],  provide  standard  formats  for  describ¬ 
ing  services  offered  by  a  component  and  runtime  facilities  to 
locate,  load,  and  execute  services  of  other  components. 
Since  these  models  are  concerned  with  low  -level  implemen¬ 
tation  issues  and  provide  little  or  no  guidance  in  building  a 
system  out  of  components,  their  use  is  neither  subsumed  by 
or  restricted  by  C2.  In  fact,  these  models  may  be  used  to 
realize  an  architecture  in  the  C2  style. 

Perhaps  the  greatest  influence  on  C2  has  been  the  grow¬ 
ing  body  of  research  on  software  architectures :  abstractions 
for  representing  high-level  structure  of  (potentially  large) 
systems,  languages  for  modeling  those  abstractions,  and 
tools  to  support  specification,  analysis,  and  implementation 
of  architectures.  Examples  of  relevant  approaches  are 
Rapide  [14].  Wright  [1].  UniCon  [34].  MetaH  [42].  and  Dar- 
w"in  [15].  C2  in  particular  shares  the  basic  vocabulary  with 
architecture  description  languages  (ADLs)  like  Wright  and 
UniCon,  which  explicitly  focus  on  software  connectors  as 
first-class  entities  in  describing  architectures.  Recognizing 
that  connectors  play  a  primary  role  in  software  architectures 
enables  the  separation  of  computation  form  communication 
and  thus  fosters  system  reconfigurability. 

It  is  this  explicit  treatment  of  connectors  that,  for  exam¬ 
ple.  directly  distinguishes  C2  from  more  traditional  layered 
systems,  such  as  network  systems  (e.g.,  Avoca  [2])  and 
operating  systems.  Connectors  provide  a  level  of  indirection 
that  reduces  dependencies  among  computational  elements 
(components).  Coupled  writh  implicit  invocation  and  domain 
translation,  this  indirection  gives  developers  more  flexibility 
in  building  systems  out  of  (existing)  components  whose 
interfaces  do  not  match  perfectly,  and  enhancing  such  sys¬ 
tems  incrementally  as  additional  (needed)  functionality 
becomes  available.  For  example,  a  C2  connector  can  decide 
to  route  some  of  the  requests  that  were  initially  handled  (and 
possibly  ignored)  by  component  X  to  the  new  component  Y. 
which  can  process  them  faster  and/or  provide  higher-preci¬ 
sion  results.  From  the  stand  point  of  components  which  are 
below"  them  in  a  C2  architecture.  X  and  Y  comprise  a  single 
component,  as  illustrated  in  Fig.  3. 


Fig.  3.  An  example  (partial)  architecture  built  according  to  C2  style  rules. 
The  architecture  demonstrates  C2’s  support  for  reconfigurability:  compo¬ 
nent  Y  has  been  added  to  an  existing  architecture  and  connector  B1  routs  to 
it  some  of  the  requests  that  used  to  be  delivered  to  component  X.  None  of 
the  components  below  B1  (e.g.,  Comp2  and  Comp3)  need  to  be  updated  m 
any  manner,  as  they  are  effectively  still  communicating  with  a  single  com¬ 
ponent. 


III.  Implementing  C2-Style  Architectures 

The  ultimate  goal  of  any  software  design  and  modeling 
endeavor  is  to  produce  the  executable  system.  An  elegant 
and  effective  architectural  model  is  of  limited  value  unless  it 
can  be  converted  into  a  running  application.  Doing  so  manu¬ 
ally  may  result  in  many  problems  of  consistency  and  trace- 
ability  between  an  architecture  and  its  implementation.  For 
example,  it  may  be  difficult  to  guarantee  or  demonstrate  that 
a  given  system  correctly  implements  an  architecture.  Fur¬ 
thermore,  even  if  this  is  currently  the  case,  one  has  no  means 
of  ensuring  that  future  changes  to  the  system  are  appropri¬ 
ately  traced  back  to  the  architecture  and  vice  versa.  It  is, 
therefore,  desirable,  if  not  imperative,  for  architecture-based 
software  development  approaches  to  provide  source  code 
generation  tools. 
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Fig.  4.  C2  object-onented  class  framework. 


To  support  implementation  of  C2  architectures,  we  devel¬ 
oped  an  extensible  framework  of  abstract  classes  for  C2 
concepts  such  as  components,  connectors,  and  messages, 
shown  in  Fig.  4.  This  fr  amework  is  the  basis  of  development 
and  OTS  component  reuse  in  C2.  It  implements  component 
interconnection  and  message  passmg  protocols.  Compo¬ 
nents  and  connectors  used  in  C2  applications  are  subclassed 
from  the  appropriate  abstract  classes  in  the  framework.  This 
guarantees  their  interoperability,  eliminates  many  repetitive 
programming  tasks,  and  allows  developers  of  C2  applica¬ 
tions  to  focus  on  application-level  issues,  hi  order  to  incor¬ 
porate  OTS  components  into  a  C2  architecture,  they  are 
wrapped  inside  framework  components,  as  shown  in  Fig.  5. 
The  framework  supports  a  variety  of  implementation  config¬ 
urations  for  a  given  architecture:  the  entire  resulting  system 
may  execute  in  a  single  due  ad  of  control,  or  each  compo¬ 
nent  may  run  in  its  own  thread  of  control  or  operating  sys¬ 
tem  (OS)  process. 

The  framework  has  been  implemented  hi  C++  and  Java;3 
a  subset  is  also  available  hi  Ada.  Hie  size  of  the  framew  ork 
hi  both  C++  and  Java  is  approximately  3000  commented 
source  lines  of  code.  We  have  been  able  to  successfully 
reuse  the  Q  interprocess  communication  (IPC)  library  [16] 
to  enable  message  exchange  between  C2  components  imple¬ 
mented  in  C++  and  Ada.  Similar  functionality  for  Java  C2 
components  is  under  development. 


OTS 

Component 


Fig.  5.  An  OTS  component  is  wrapped  inside  a  C2  component. 

We  have  also  used  the  C++  and  Java  framew  orks  to  inte¬ 
grate  the  Xlib  [33]  and  Java  AWT  [7]  user  interface  toolkits, 
respectively.  By  essentially  wrapping  diem  in  the  manner 
depicted  hi  Fig.  5,  they  become  C2  “graphics  binding”  com¬ 
ponents.  Such  graphics  bindings  are  needed  shice  many 
potential  C2  components,  such  as  these  commercial  toolkits, 
have  interface  conventions  that  do  not  match  up  with  C2's 
notifications  and  requests.  Typically  these  systems  wrill  gen¬ 
erate  events  of  the  form  “this  w  indowr  has  been  selected”  or 
“the  user  has  typed  the  ‘x’  key”  and  send  them  up  an  archi¬ 
tecture.  These  toolkit  events  w'ill  need  to  be  converted  into 
C2  requests.  Conversely,  notifications  from  a  C2  architec¬ 
ture  will  have  to  be  converted  to  the  type  of  invocations  that 
a  toolkit  expects,  hi  order  for  these  translations  to  occur  and 
be  meaningful,  careful  thought  has  to  go  hito  the  design  of 
the  graphics  bindings  such  that  they  contain  the  required 
functionality  and  are  reusable  across  architectures  and  appli¬ 
cations.  hi  integrating  Xlib  and  AWT,  we  drew'  from  our 
experience  hi  adapting  Motif  and  OpenLook  for  use  in  Chi¬ 
ron- 1  [40], 

Our  current  approach  to  implementing  C2  architectures  is 
implementation  constraining  [21]:  there  is  a  1-to-l  relation¬ 
ship  betw  een  the  components  hi  the  architecmral  model  and 
those  hi  its  corresponding  implementation.  It  is  important  to 
note  that  tins  is  a  property  of  our  current  toolset,  and  not  of 
C2.  C2  allows  arbitrary  mappings  of  conceptual  to  concrete 
components  [19].  At  the  same  time,  w  hile  limiting  hi  certain 
regards  (e.g..  the  performance  of  systems  implemented  hi 
this  maimer  w'ill  not  always  be  adequate),  tins  approach  has 
enabled  us  to  produce  implementation  prototypes  of  C2 
architectures  quickly  and  reliably.  This  has,  hi  turn,  allowed 
us  to  focus  our  attention  on  other  facets  of  C2,  such  as 
dynamic  change  of  C2  architectures  [24],  expansion  to 
domains  other  than  GUT  software  [20],  and  C2’s  suitability 
and  support  for  OTS  component  integration  and  develop¬ 
ment  of  application  families,  discussed  belowr. 

IV.  Overview  of  KLAX 

The  architecture  that  wras  used  as  the  basis  for  our  investi¬ 
gation  of  OTS  component  integration  hi  C2  is  a  version  of 
the  video  game  KLAX.  A  description  of  the  game  is  given 
in  Fig.  6.  This  particular  application  was  chosen  as  a  useful 
test  of  the  C2  style  concepts  in  that  the  game  is  based  on 
common  computer  science  data  structures  and  game  play 
imposes  some  real-time  constraints  on  the  application. 


3.  The  C++  and  Java  framew  orks  and  several  simple  applications  dev  eloped 
with  them  are  available  at  http://www.ics.uci.edu/pub/arch/. 


bringing  performance  issues  to  the  forefront. 


KLAX  Chute 

Tiles  of  random  colors 
drop  at  random  times 
and  locations. 
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Palette  catches  tiles  coming 
down  the  Chute  and  drops 
them  into  the  Well. 

KLAX  Well 

Horizontal,  vertical,  and 
diagonal  sets  of  three  or 
more  consecutive  tiles  of 
the  same  color  are  removed 
and  any  tiles  above  them 
collapse  down  to  fill  in  the 
newly-created  empty  spaces. 

KLAX  Status 


Fig.  6.  A  screenshot  and  description  of  our  implementation  of  the  KLAX 
video  game. 

The  architecture  of  the  system  is  depicted  in  Fig.  7.  The 
components  that  make  up  the  KLAX  game  can  be  divided 
into  three  logical  groups.  At  the  top  of  the  architecture  are 
the  components  which  encapsulate  the  game’s  state.  These 
components  are  placed  at  the  top  since  game  state  is  vital  for 
the  functioning  of  the  other  two  groups  of  components.  The 
game  state  components  receive  no  notifications,  but  respond 
to  requests  and  emit  notifications  of  internal  state  changes. 
Notifications  are  directed  to  the  next  level,  where  they  are 
received  by  both  the  game  logic  components  and  the  artist 
components.4 

The  game  logic  components  request  changes  of  game 
state  in  accordance  with  game  rules  and  interpret  game  state 
change  notifications  to  determine  the  state  of  the  game  in 
progress.  For  example,  if  a  tile  is  dropped  from  the  well, 
RelativePositioningLogic  determines  if  the  palette  is  in  a 
position  to  catch  the  tile.  If  so,  a  request  is  sent  to  Pal- 
etteADT  to  catch  the  tile.  Otherwise,  a  notification  is  sent 
that  a  tile  has  been  dropped.  This  notification  is  detected  by 
StatusLogic,  causing  the  number  of  lives  to  be  decremented. 

The  artist  components  also  receive  notifications  of  game 
state  changes,  causing  them  to  update  their  depictions.  Each 
artist  maintains  the  state  of  a  set  of  abstract  graphical  objects 
which,  when  modified,  send  state  change  notifications  in  the 
hope  that  a  lower-level  graphics  component  will  render 
them  on  the  screen.  TileArtist  provides  a  flexible  presenta¬ 
tion  for  tiles.  Artists  maintain  information  about  the  place¬ 
ment  of  abstract  tile  objects.  TileArtist  intercepts  any 
notifications  about  tile  objects  and  recasts  them  to  notifica¬ 
tions  about  more  concrete  drawable  objects.  For  example,  a 
“Tile-Created”  notification  might  be  translated  into  a  “Rect¬ 
angle-Created”  notification.  The  LayoutManager  compo¬ 
nent  receives  all  notifications  from  the  artists  and  offsets  any 
coordinates  to  ensure  that  the  game  elements  are  drawn  in 


4.  An  artist  is  a  component  that  creates  an  abstract  depiction  of  the  data  it 
receives.  That  abstract  depiction  can  then  be  transformed  into  a  screen 
image  by  a  rendering  agent  (in  our  case,  C2’s  graphics  binding  component). 


the  correct  two-dimensional  juxtaposition. 

The  Graphic sBinding  component  receives  all  notifica¬ 
tions  about  the  state  of  the  artists’  graphical  objects  and 
translates  them  into  calls  to  a  window  system.  User  events, 
such  as  a  key  press,  are  translated  into  requests  to  the  artist 
components. 


Fig.  7.  Conceptual  C2  architecture  for  KLAX. 

The  KLAX  architecture  is  intended  to  support  a  family  of 
“falling-object”  games.  The  components  were  designed  as 
reusable  building  blocks  to  support  different  game  varia¬ 
tions.  One  such  variation  is  described  in  [39]. 

The  KLAX  implementation  is  built  using  the  C++  frame¬ 
work.  The  implementation  consists  of  approximately  8100 
lines  of  commented  C++  code,  in  addition  to  the  base  frame¬ 
work’s  3000  lines  of  code.  Performance  of  the  implementa¬ 
tions  is  good  on  a  Sun  Sparc2  workstation,  easily  exceeding 
human  reaction  time  if  the  ClockLogic  component  is  set  to 
use  short  time  intervals.  Although  we  have  not  yet  tried  to 
optimize  performance,  benchmarks  indicate  that  our  current 
framework  can  send  1200  simple  messages  per  second  when 
sending  and  receiving  components  are  in  the  same  process. 
In  the  KLAX  system,  a  keystroke  typically  causes  10  to  30 
message  sends,  and  a  tick  of  the  clock  typically  causes  3  to 
20. 


V.  KLAX  Constraints 

In  its  form  as  described  above,  KLAX  does  not  necessar¬ 
ily  need  a  constraint  solver.  Its  constraint  management  needs 
would  certainly  not  exploit  the  full  power  of  a  solver  such  as 
SkyBlue,  e.g.,  handling  constraint  hierarchies  [32].  On  the 
other  hand,  we  think  it  should  be  possible  to  use  a  powerful 
constraint  manager  for  maintaining  a  small  number  of  sim¬ 
ple  constraints.  Additionally,  the  main  purpose  of  this  effort 
was  to  explore  the  architectural  issues  in  integrating  OTS 
components  into  a  C2  architecture.  We  therefore  opted  not 
to  unnecessarily  expend  resources  to  artificially  create  a  sit¬ 
uation  where  a  number  of  complex  constraints  needed  to  be 
managed.  Instead,  we  decided  to  integrate  SkyBlue  with 
KLAX  to  support  its  extant  constraint  management  needs.  If 
we  were  unable  to  do  so,  there  would  be  at  least  three  possi- 


ble  sources  of  problems:  (1)  the  C2  style,  (2)  the  KLAX 
architecture,  and  (3)  SkyBlue.  In  any  case,  we  would  leam  a 
useful  lesson. 

We  defined  the  following  4  constraints  for  management 
by  SkyBlue: 

•  Palette  Boundary:  The  palette  cannot  move  beyond  the 
chute  and  well's  leff  and  right  boundaries. 

•  Palette  Location:  Palette’s  coordinates  are  a  function  of 
its  location  and  are  updated  every  time  the  location 
changes.5 

•  Tile  Location:  The  tiles  which  are  on  the  palette  move 
with  the  palette.  In  other  words,  the  x  coordinate  of  the 
center  of  the  tile  always  equals  the  x  coordinate  of  the 
center  of  the  palette. 

•  Resizing:  Each  game  element  (chute,  well,  palette,  and 
tiles),  is  maintained  in  an  abstract  coordinate  system  by  its 
artist.  This  constraint  transforms  those  abstract  coordmate 
systems,  resizing  the  game  elements  to  have  the  relative 
dimensions  depicted  in  Fig.  6  before  they  are  rendered  on 
the  screen.  This  constraint  would  be  essential  in  a  case 
where  the  application  is  composed  from  preexisting  com¬ 
ponents  supplied  by  different  vendors.  A  similar  con¬ 
straint  could  also  be  used  to  acconunodate  resizing  of  the 
game  window,  and  hence  of  the  game  elements  within  it. 

VI.  Integrating  External  Constraint  Managers  with 
KLAX 

VI. A.  Integrating  SkyBlue 

Hie  four  constraints  were  defined  based  on  the  needs  of 
the  overall  application.  Further  thought  was  still  needed  to 
decide  the  location  of  the  constraint  manager  in  the  KLAX 
architecture.  There  clearly  were  several  possibilities.  One 
solution  would  have  been  to  include  SkyBlue  within  the 
appropriate  components  for  the  Palette  Boundary,  Palette 
Location,  and  Tile  Location  constraints,  since  they  affect 
individual  game  elements  (i.e.,  they  are  "local”).  The  Resiz¬ 
ing  constraint  pertains  to  several  game  elements,  and  would 
thus  belong  in  a  separate  component. 


•  •  • 


Fig.  8.  The  SkyBlue  constraint  management  system  is  incorporated  into 
KLAX  by  placmg  it  inside  the  LayoutManager  component.  LayoutMan¬ 
ager  s  dialog  handles  all  the  C2  message  traffic. 

We  initially  opted  for  another  solution:  define  all  four 
constraints  in  a  centralized  constraint  manager  component. 
The  LayoutManager  component  was  intended  to  serve  as  a 


5.  Location  is  an  integer  between  1  and  5. 


constraint  manager  in  the  original  design  of  KLAX  shown 
in  Fig.  7.  However,  in  the  initial  implementation,  the  con¬ 
straints  were  solved  with  in-line  code  locally  in  PaletteADT 
and  PaletteArtist  and  the  sole  purpose  of  LayoutManager 
was  to  properly  line  up  game  elements  on  the  screen.  The 
implemented  version  of  LayoutManager  also  placed  the  bur¬ 
den  of  ensuring  that  the  game  elements  have  the  same  rela¬ 
tive  dimensions  on  the  developers  of  the  PaletteArtist, 
ChuteArtist,  and  WellArtist  components.  Incorporating  con¬ 
straint  management  functionality  into  LayoutManager 
therefore  rendered  an  implementation  more  faithful  to  its 
original  design. 

The  constraints  were  defined  in  the  "dialog  and  con¬ 
straints”  part  of  the  LayoutManager  component  (see  Fig.  2), 
while  SkyBlue  became  the  component's  internal  object.  As 
such,  SkyBlue  has  no  knowledge  of  the  architecture  of 
which  it  is  now  a  pari.  It  maintains  the  constraints,  while  all 
the  request  and  notification  traffic  is  handled  by  LayoutMan¬ 
ager'  s  dialog,  as  shown  in  Fig.  8.  LayoutManager  thus 
became  a  constraint  management  component  in  the  C2  style 
that  can  be  reused  in  other  applications  by  only  modifying 
its  dialog  to  include  new  constraints.6 

PaletteADT.  PaletteArtist.  ChuteArtist.  and  WellArtist  also 
needed  to  be  modified.  Their  local  constraint  management 
code  was  removed.  Furthermore,  their  dialogs  and  message 
interfaces  were  expanded  to  notify  LayoutManager  of 
changes  in  constraint  variables  and  to  handle  requests  from 
LayoutManager  to  update  them. 

It  is  important  to  note  that  it  was  not  necessary  to  modify 
these  four  components  in  order  for  the  architecture  contain¬ 
ing  the  new'  LayoutManager  to  behave  correctly.  However, 
just  like  the  original  LayoutManager  wTas  modified  to  reflect 
its  intent,  these  components’  implementations  w;ere  modi¬ 
fied  to  mirror  their  intended  behavior  as  wrell.  As  already 
discussed  in  the  preceding  section,  building  this  new'  version 
of  LayoutManager  and  inserting  it  into  the  architecture  was 
not  motivated  by  the  need  for  functionality  that  did  not 
already  exist  in  the  architecture  (the  application  had  already 
behaved  as  desired).  Rather,  the  drivers  w'ere  improved 
traceability  of  architectural  decisions  to  the  implementation 
and  vice  versa,  construction  of  a  powerful  constraint  man¬ 
agement  component  in  the  C2  style,  and  investigation  of 
issites  in  integrating  OTS  components  into  C2-style  archi¬ 
tectures.  This  matter  is  further  discussed  below'  in 
Section  VIELB. 

1 1  new'  messages  wrere  added  to  handle  this  modification 
of  the  original  application  and  there  w'as  no  perceptible  per¬ 
formance  degradation.  The  entire  exercise  wras  completed 
by  one  developer  in  approximately  45  hours. 

VI.  B.  Integrating  Amulet 

C2  supports  reuse  through  component-based  develop¬ 
ment.  substrate  independence,  and  domain  translation. 
These  features  also  support  component  substitutability  and 
localization  of  change.  We  claim  that,  in  general,  two  behav- 
iorally  equivalent  components  can  ahvays  be  substituted  for 
one  another  and  that  behavior  preserving  modifications  to  a 
component's  implementation  have  no  architecture-w'ide 


6.  In  the  remainder  of  the  paper,  when  we  state  that  a  constraint  solver  is 
“inside”  or  internal  to”  a  component,  the  internal  architecture  of  the  com¬ 
ponent  wrill  resemble  that  of  LayoutManager  from  Fig.  8. 


effects  [19]. 

In  the  example  discussed  in  the  previous  section,  this 
would  mean  that  SkyBlue  may  be  replaced  with  another 
constraint  manager  by  only  having  to  modify  the  “dialog 
and  constraints”  portion  of  LayoutMcmager  to  define  con¬ 
straints  as  required  by  the  new  solver.  The  set  of  messages  in 
L ayoutManagei ■ ' s  interface  and  the  rest  of  the  KLAX  archi¬ 
tecture  would  remain  unchanged. 

To  demonstrate  this  claim,  we  substituted  SkyBlue  with 
Amulet’s  one-way  formula  constraint  solver  [17].  This  exer¬ 
cise  required  identifying,  extracting,  and  recompiling  the 
needed  portion  of  Amulet,  a  task  that  was  accomplished  by 
a  single  developer  in  approximately  25  hours.7  This  added 
effort  was  necessitated  by  our  inability  to  locate  implemen¬ 
tations  of  any  other  constraint  solvers.  It  resulted  in  a  situa¬ 
tion  that  is  common  when  attempting  software  reuse:  OTS 
systems  may  not  contain  components  that  can  be  clearly 
identified  or  easily  isolated  and  extracted  [4],  [9],  [13]. 

Once  die  solver  was  extracted  from  the  rest  of  Amulet,  it 
was  successfully  substituted  for  SkyBlue  in  the  KLAX 
arclii tec tiue  and  tested  by  one  developer  in  75  minutes.  As 
anticipated,  no  architecture-wide  changes  were  needed. 
Only  the  interior  of  the  LayoutManager  component  needed 
to  be  modified:  its  internal  object  was  now  Amulet  instead 
of  SkyBlue;  the  constraint  variables  updated  by  the  compo¬ 
nent’s  dialog  in  response  to  incoming  C2  messages  were 
now  defined  in  Amulet.  The  look-and-feel  of  the  application 
remained  unchanged.  There  was  again  no  performance  deg¬ 
radation. 

VII.  KLAX  Component  Library 

Integrating  SkyBlue  and  Amulet  with  KLAX  provided  an 
opportunity  for  building  multiple  versions  of  PaletteADT. 
PaletteArtist,  Chute  Artist,  WellArtist,  and  LayoutManager 
components.  Individual  versions  of  each  component  would 
differ  based  on  two  criteria: 

•  constraints  maintained  —  if  two  versions  of  a  component 
maintain  different  constraints  internally,  then  message 
interfaces  will  also  differ  to  account  for  that.  Extreme 
cases  are  (1)  components  that  enforce  all  of  their  local 
constraints  and  (2)  those  that  enforce  no  constraints. 

•  mechanism  used  for  constraint  maintenance  —  a  compo¬ 
nent  can  maintain  a  constraint  (1)  with  in-line  code,  as  in 
the  original  implementation.  (2)  in  SkyBlue,  (3)  in  Amu¬ 
let.  or  (4)  using  a  combination  of  the  three. 

The  two  integrations  described  in  the  previous  section 
resulted  in  three  versions  of  LayoutManager.  the  original. 
SkyBlue.  and  Amulet  versions.  These  are  listed  as  Layout- 
Manager  versions  1.  2.  and  3  in  Table  1.  Two  versions  each 
of  PaletteADT.  PaletteArtist.  ChuteArtist.  and  WellArtist 
were  created  as  well:  original  components  maintaining  local 
constraints  with  in-line  code  (versions  1  of  the  four  compo¬ 
nents  in  Table  1)  and  components  whose  constraints  were 
managed  elsewhere  in  the  architecture  (versions  2  of  the 
four  components  in  Table  l).8 


7.  For  the  purpose  of  brevity,  in  the  remainder  of  the  paper  Amulet’s  one¬ 
way  formula  constraint  manager  will  be  referred  to  simply  as  “Amulet.’’ 


Table  1:  Implemented  Versions  of  PaletteADT,  PaletteArtist, 
ChuteArtist ,  WellArtist ,  and  LayoutManager  KLAX  Components 


Version 

Number 

Constraints 

Maintained 

Constraint 

Managers 

jt  — 

i 

Palette  Boundary 

In-Line  Code 

2 

None 

None 

3 

Palette  Boundary 

SkyBlue 

4 

Palette  Boundary 

Amulet 

Paid  tv 

Artist 

1 

Palette  Location 

Tile  Location 

Tile  Size 

In-Line  Code 

2 

None 

None 

3 

Palette  Location 

Tile  Location 

SkyBlue 

4 

Palette  Location 

Tile  Location 

Amulet 

Chute 

Vrtist 

1 

Chute  Size 

In-Line  Code 

2 

None 

None 

Well 

\rt  ist 

1 

Well  Size 

In-Line  Code 

2 

None 

None 

u 

i  si 

O  rz 

si 

1 

None 

None 

2 

All 

SkyBlue 

3 

All 

Amulet 

4 

Resizing 

SkyBlue 

5 

Resizing 

Amulet 

6 

All 

SkyBlue  &  Amulet 

The  two  initial  integrations  also  suggested  other  varia¬ 
tions  of  these  components,  such  as  replacing  in-line  con¬ 
straint  management  code  with  SkyBlue  and  Amulet 
constr  aints  in  PaletteADT  and  PaletteArtist  (see  Footnote  6). 
Also,  a  version  of  LayoutManager  was  implemented  that 
maintained  only  the  Resizing  constraint,  in  anticipation  that 
other  components  will  internally  manage  their  local  con¬ 
straints  (this  scenario  was  briefly  described  at  the  beginning 
of  Section  VI).  This  resulted  in  a  total  of  18  implemented 
versions  of  the  five  components,  as  depicted  in  Table  1 . 

MIL  Building  a  Program  Family 

The  four  versions  of  PaletteADT  and  PaletteArtist ,  two 
versions  of  ChuteArtist  and  WellArtist,  and  six  versions  of 
LayoutManager,  described  in  Table  1,  could  potentially  be 
used  to  build  384  different  variations  of  the  KLAX  architec¬ 
ture.  i.e..  members  of  the  KLAX  application  family.  Three 
such  variations  were  described  hr  Section  IV  (using  versions 
1  of  all  five  components),  Section  VI.A  (using  versions  2  of 
the  five  components),  and  Section  VLB  (replacing  Layout- 
Manager-2  with  LayoutManager -3  in  the  architecture  from 
Section  VI).  In  this  section,  we  discuss  several  additional 
implemented  variations  of  the  architecture  that  exhibit  inter¬ 
esting  properties. 

VIII.  A.  Multiple  Instances  of  a  Constraint  Manager 

In  the  architecture  depicted  hr  Table  2.  the  Palette  Bound- 
aiy.  Palette  Location,  and  Tile  Location  constraints  are 
defined  and  maintained  in  SkyBlue  mside  PaletteADT  and 


8.  In  the  rest  of  the  paper,  a  particular  component  version  will  be  depicted 
by  die  component  name  followed  by  version  number  (e  g.,  PaIetteADT-2). 


PaletteArtist,  while  the  Resizing  constraints  are  maintained 
globally  by  LayoutManager.  Therefore,  multiple  instances 
of  SkyBlue  maintain  the  constraints  in  different  KLAX 
components.  Since  C2  separates  architecture  from  imple¬ 
mentation.  we  were  able  to  implement  the  three  components 
that  contain  their  own  logical  copies  of  SkyBlue  using  a  sin¬ 
gle  physical  instance  of  the  constraint  manager. 


Table  2:  Multiple  Instances  of  SkyBlue 


Component 

Version 

Number 

Constraints 

Maintained 

Constraint 

Managers 

PaletteADT 

3 

Palette  Boundary 

SkyBlue 

PaletteArtist 

3 

Palette  Location 
Tde  Location 

SkyBlue 

ChuteArtisf 

2 

None 

None 

WellArtist 

2 

None 

None 

LayoutManager 

4 

Resizing 

SkyBlue 

VUI.B.  Partial  Communication  and  Senice  Utilization 
Particularly  interesting  are  components  that  are  used  in  an 
architecture  for  which  they  have  not  been  specifically 
designed,  i.e..  they  can  do  more  or  less  than  they  are  asked 
to  do.  This  is  an  issue  of  reuse:  if  we  build  components  a 
certain  way.  are  their  users  (designers)  always  obliged  to  use 
them  “fully”:  furthermore,  can  meaningful  work  be  done  in 
an  architecture  if  two  components  communicate  only  par¬ 
tially.  i.e.,  certain  messages  are  lost?  The  architectures 
described  below  represent  a  crossection  of  exercises  con¬ 
ducted  to  better  our  understanding  of  partial  communication 
and  partial  component  sen  ice  utilization. 

•  A  variation  of  the  original  architecture  was  implemented 
by  substituting  LayoutManager- 2  into  the  original  archi¬ 
tecture,  as  shown  in  Table  3.  LayoutManager-2' s  func¬ 
tionality  remains  largely  unused  as  no  notifications  are 
sent  to  it  to  maintain  the  constraints  (see  Section  VI.A). 
The  application  still  behaves  as  expected  and  there  is  no 
performance  penalty.  Note  that  this  will  not  always  be  the 
case:  if  LayoutManager-2  was  substantially  larger  than 
LayoutManager- 1  or  had  much  greater  system  resource 
needs  (e.g..  its  own  operating  system  process),  the  perfor¬ 
mance  would  be  affected. 


Table  3:  None  of  LayoutManager' %  Constraint  Management 
Functionality  is  Utilized 


Component 

Version 

Number 

Constraints 

Maintained 

Constraint 

Managers 

PaletteADT 

i 

Palette  Boundary 

In-Line  Code 

PaletteArtist 

i 

Palette  Location 
Tile  Location 
Palette  Size 

In-Line  Code 

ChuteArtisf 

i 

Chute  Size 

In-Line  Code 

WellArtist 

i 

Well  Size 

In-Line  Code 

LayoutManager 

2 

All 

SkyBlue 

•  Another  architecture  that  was  built  is  shown  in  Table  4. 
This  exercise  was  intended  to  explore  heterogeneous 
approaches  to  constraint  maintenance  in  a  single  architec¬ 
ture:  some  components  in  the  architecture  maintain  their 
constraints  with  in-line  code  {Well Artist  and  ChuteArtisf), 
others  maintain  them  internally  using  SkyBlue  {Pal¬ 
etteADT),  while  Palette  Artist's,  constraints  are  maintained 
by  an  external  constraint  manager.  LayoutManager-2  is 


still  partially  utilized,  but  a  larger  subset  of  its  services  is 
used  than  in  the  preceding  architecture. 

Table  4:  LayoutManager* s  Constraint  Management  Functionality  is 
Only  Partially  Utilized 


Component 

Version 

Number 

Constraints 

Maintained 

Constraint 

Managers 

PaletteADT 

3 

Palette  Boundary 

SkyBlue 

PaletteArtist 

2 

None 

None 

ChuteArtisf 

1 

Chute  Size 

In-Line  Code 

WellArtist 

1 

Well  Size 

In-Line  Code 

LayoutManager 

2 

All 

SkyBlue 

•  In  the  architecture  shown  in  Table  5,  PaletteADT  expects 
that  the  Palette  Boundary  constraint  w  ill  be  maintained 
externally  by  some  other  component.  How'ever.  in  this 
case.  LayoutManager-l  does  not  understand  and  therefore 
ignores  the  notifications  sent  by  PaletteADT  (partial  com¬ 
munication).  Movement  of  the  palette  is  thereby  not  con¬ 
strained  and  the  application  behaves  erroneously:  the 
palette  disappears  when  moved  beyond  its  right  boundary; 
the  execution  aborts  when  the  palette  mov  es  beyond  the 
left  boundary  and  the  GraphicsBinding  component  (see 
Section  IV)  attempts  to  render  it  at  negativ  e  screen  coor¬ 
dinates. 


Table  5:  Palette  Boundary'  Constraint  is  not  Maintained 


Component 

Version 

Number 

Constraints 

Maintained 

Constraint 

Managers 

PaletteADT 

2 

None 

None 

PaletteArtist 

1 

Palette  Location 
Tile  Location 
Palette  Size 

In-Line  Code 

ChuteArtisf 

1 

Chute  Size 

In-Line  Code 

WellArtist 

1 

Well  Size 

In-Line  Code 

LayoutManager 

1 

None 

None 

The  abov  e  examples  seem  to  imply  that  partial  service 
utilization  generally  has  no  ill  effects  on  a  system,  wiiile 
partial  communication  does.  This  is  not  ahvays  the  case.  For 
example,  an  additional  version  of  each  component  from  the 
original  architecture  was  built  to  enable  testing  of  the  appli¬ 
cation.  These  components  would  generate  notifications  that 
ware  needed  by  both  components  below'  them  in  the  archi¬ 
tecture  and  the  testing  harness.  If  a  “testing”  component  was 
inserted  into  the  original  architecture,  all  of  its  testing- 
related  messages  w'ould  be  ignored  by  components  below'  it, 
resulting  in  partial  communication,  yet  the  application 
would  still  behave  as  expected.  Clearly,  the  overhead  of  dis¬ 
patching  messages  that  ultimately  get  ignored  may  be  pro¬ 
hibitively  expensive  in  certain  situations.  In  general,  a  useful 
metric  for  determining  the  potentially  negative  effects  of 
partial  communication  w'ould  be  the  ratio  of  the  number  of 
lost  messages  to  the  total  number  of  messages  in  an  archi¬ 
tecture. 

VIII.  C.  Multiple  Constraint  Managers  in  a  Single 
Component 

LayoutManager-6  had  some  of  its  constraints  defined  in 
SkyBlue  and  others  in  Amulet.  Combining  multiple  con¬ 
straint  solvers  in  a  single  system  has  only  recently  been 
identified  as  a  potentially  useful  approach  to  constraint  man- 


agement  [17],  [32].  Integrating  multiple  constraint  solvers  in 
a  single  C2  component  is  certainly  at  a  different  level  of 
granularity.  However,  this  exercise  sensitized  us  to  several 
issues  intrinsic  to  the  interaction  of  heterogeneous  constraint 
managers. 

Specifying  constraints  hi  different  solvers  over  disjoint 
sets  of  variables  is  a  trivial  task,  since  there  are  no  depen¬ 
dencies  between  the  solvers.  On  the  other  hand,  if  the  two 
sets  of  constraint  variables  intersect,  die  problem  is  more 
complex,  hi  our  case,  constraint  variables  in  SkyBlue  and 
Amulet  are  of  different  types,  so  that  the  same  variable  can¬ 
not  be  used  in  constraints  specified  in  both  solvers.  There¬ 
fore.  each  conceptually  common  variable  is  implemented  by 
two  actual  variables  (yarSkyBlue  and  var_Amulet).  Fur¬ 
thermore.  additional  functionality  is  needed  to  monitor  the 
changes  in  the  variables  and  programmatically  update  one 
when  the  other  is  changed  due  to  constraint  enforcement 
(see  Fig.  9). 


Fig.  9.  To  provide  consistent  constraint  maintenance  across  constraint  solv¬ 
ers,  each  conceptually  common  constraint  variable  (CV)  is  implemented 
with  two  actual  variables.  Changes  m  one  are  automatically  reflected  m  the 
other. 

For  example,  in  LayoutManager-6,  Palette  Boundary,  Tile 
Location,  and  Resizing  constraints  are  defined  in  SkyBlue, 
while  Palette  Location  is  specified  in  Amulet.  Every  tune 
locationJSkyBlue  changes,  its  new  value  is  assigned  to 
location  Amulet  so  that  Amulet  can  properly  update  the 
paletteX  Amulet  variable.  To  propagate  its  change  through 
the  rest  of  SkyBlue  variables,  pa1etteX_Amulef  s  new  value 
is  copied  into paletteX_SkyBlue. 

Our  solution  to  defining  SkyBlue  and  Amulet  constraints 
over  overlapping  sets  of  variables,  although  effective,  was 
not  particularly  elegant.  It  had  the  feel  of  programming 
one’s  own  application-specific  constraint  management  func¬ 
tionality.  While  the  purpose  of  the  exercise  was  to  investi¬ 
gate  issues  pertinent  to  sofhvare  architectures  and 
application  families,  this  problem  has  broader  ramifications. 
A  scenario  where  both  a  powerful  but  complex  solver  and  a 
simple  one  are  needed  in  an  application  is  likely.  Therefore, 
we  consider  the  problem  of  multiple  interacting  constraint 
managers  an  open  research  issue  that  requires  careful  exam¬ 
ination.  We  are  currently  exploring  what  role  an  architec¬ 
tural  style  such  as  C2,  and  particularly  its  support  for 
compositionality.  may  play  in  the  resolution  of  this  problem. 

VIII. D.  Multiple  Constraint  Managers  in  an 
Architecture 

An  issue  related  to  using  multiple  constraint  managers 
inside  a  single  component  is  using  multiple  constraint  man¬ 
agers  in  different  components,  but  in  a  single  architecture. 
Such  an  architecture  was  built  using  components  shown  in 
Table  6.  hi  this  architecture.  Palette  Boundary  and  Resizing 
constraints  are  maintained  by  SkyBlue,  and  Palette  Location 


and  Tile  Location  by  Amulet.  Since  the  sets  of  constraint 
variables  managed  by  the  two  solvers  are  disjoint,  there  are 
no  interdependencies  of  the  kind  discussed  in  the  previous 
example  between  SkyBlue  and  Amulet.9  Hence,  this  modifi¬ 
cation  to  the  architecture  was  a  simple  one. 


Table  6:  Multiple  Constraint  Solvers 


Component 

Version 

Number 

Constraints 

Maintained 

Constraint 

Managers 

PaletteADT 

3 

Palette  Boundary 

SkyBlue 

PaletteArtist 

4 

Palette  Location 
Tile  Location 

Amulet 

ChuteArtist 

2 

None 

None 

WellArtist 

2 

None 

None 

LayoutManager 

4 

Resizing 

SkyBlue 

IX.  Related  Approaches 

Explicit  focus  on  software  architectures,  and  architectural 
styles  in  particular  have  a  great  potential  to  facilitate  both 
OTS  component  reuse  and  development  of  families  of  appli¬ 
cations.  Krueger  points  out  some  common  problems  in  bas¬ 
ing  reuse  on  software  architectures  [13],  His  criticism 
mainly  applies  to  those  approaches  that  do  not  identify 
higher-level  abstractions  applicable  across  applications.  C2, 
on  the  other  hand,  is  a  style  that  attempts  to  exploit  com¬ 
monalities  across  systems,  and  reuse  individual  components 
as  w  ell  as  successful  structural  and  communication  patterns. 

The  two  goals  of  maximizing  reuse  and  building  system 
families  do  not  ahvays  go  hand  in  hand.  For  example,  one 
focus  of  domain-specific  software  architectures  (DSSAs)  is 
on  developing  a  generic  reference  architecture  for  all  sys¬ 
tems  hi  a  particular  domain  of  applicability  [41].  The  refer¬ 
ence  architecture  is  then  instantiated  for  every  individual 
system  within  the  domain,  as  shown  hi  Fig.  10.  By  making 
reference  architectures  explicit.  DSSAs  employ  a  systematic 
approach  to  developing  application  families. 

In  the  w  ork  wre  discussed  hi  this  paper  we  do  not  develop 
a  reference  architecture  as  a  basis  for  building  the  KLAX 
application  family.  However,  there  is  also  nothing  inherent 
in  the  C2  style  that  prohibits  one  from  dohig  so.  Quite  the 
contrary,  as  an  architectural  style,  C2  can  be  applied  to  mul¬ 
tiple  domains,  each  of  which  would  require  its  own  refer¬ 
ence  architecture.  C2’s  ADL  and  underlying  formalism  [18], 
[19],  [22]  are  w’ell  suited  for  this:  each  component  hi  a  C2 
architecture  is  a  conceptual  placeholder  which  can  be 
instantiated  by  different  implemented  modules.  The  ease 
with  which  wre  wrere  able  to  build  the  application  family 
described  hi  this  paper  without  the  aid  of  a  reference  archi¬ 
tecture  is  indicative  of  C2’s  potential  hi  tins  regard. 

Unlike  then  inherent  support  for  application  families. 
DSSAs  have  tended  to  support  reuse  only  to  a  limited 
degree.  GenVoca  [2]  is  an  illustrative  example.  It  has  been 
particularly  successful  in  producing  a  large  library  of  reus¬ 
able  components.  How'ever.  those  components  have  been 
custom  built  for  the  GenVoca  style,  hi  order  to  reuse  them, 
one  must  adhere  to  GenVoca’s  formalism  and  its  hierarchi¬ 
cal  approach  to  component  composition,  which  may  result 


9.  Architectures  built  according  to  the  C2  style  will  always  have  this  prop¬ 
erty:  since  C2  does  not  assume  a  single  address  space  for  its  components, 
inter-component  constraint  variable  sets  will  always  be  disjoint. 


in  a  high  degree  of  dependency  between  communicating 
components.  On  the  other  hand.  C2’s  style  rules  and  under¬ 
lying  formalism  are  more  flexible;  C2  eliminates  assump¬ 
tions  of  shared  address  spaces  and  threads  of  control,  allows 
both  synchronous  and  asynchronous  message-based  com¬ 
munication.  and  separates  the  architecture  from  the  imple¬ 
mentation. 


Reference  Application 

Architecture  Architecture  Implementation 


Fig.  10.  A  simplified,  high-level  view  of  the  DSSA  lifecycle.  A  generic  ref¬ 
erence  architecture  is  instantiated  to  obtain  an  application-specific  architec¬ 
ture,  which  is  then  used  as  the  basis  for  implementation. 

Several  aspects  of  object-oriented  (OO)  programming 
have  provided  us  with  valuable  lessons,  hi  [19]  we  demon¬ 
strate  how  concepts  from  OO  typing  can  be  applied  to  soft¬ 
ware  architectures.  The  work  on  OO  design  patterns  [8]  has 
similarities  with  architectural  styles.  However,  OO  design 
patterns  support  reuse  of  structures  at  a  much  lower  level  of 
abstraction  than  do  styles. 

Garlan.  Allen,  and  Ockerbloom  classify  the  causes  of 
problems  developers  commonly  experience  when  attempt¬ 
ing  OTS  reuse  and  give  four  guidelines  for  alleviating  them 
[9],  Our  experience  shows  that  C2  is  well  suited  to  address 
these  problems.  The  first  two  guidelines  deal  with  the  inter¬ 
nal  architecture  of  OTS  components,  and  are  thus  outside 
the  scope  of  C2.  The  third  guideline  proposes  techniques  for 
building  component  adaptors,  which  is  subsumed  by  C2 
wrappers  and  domain  translators.  Finally,  the  authors 
emphasize  the  need  for  design  guidance,  which  is  a  signifi¬ 
cant  aspect  of  our  approach  to  C2  [30].  [31]. 

Shaw  discusses  nine  “tricks”  for  reconciling  component 
mismatch  hi  an  architecture  [35].  Several  of  the  tricks  are 
related  to  reuse  techniques  employed  in  C2.  For  example, 
transformations,  such  as  “Change  A’s  form  to  B's  form”, 
“Provide  B  with  import/export  converters”,  and  “Attach  an 
adapter  or  wrapper  to  A,”  are  subsumed  by  C2’s  wrappers 
and/or  domain  translators.  The  need  for  other  transforma¬ 
tions  is  eliminated  altogether  by  C2  style  rules.  For  exam¬ 
ple.  “Make  B  multilingual”  is  unnecessary,  as  C2  assumes 
that  components  will  be  heterogeneous  and  multilingual. 

X.  Conclusion 

The  full  potential  of  component-based  softw  are  architec¬ 
tural  styles  cannot  be  realized  unless  reusing  code  developed 
by  others  becomes  a  common  practice.  A  new’  architectural 
style  can  become  a  standard  in  its  domain  only  if  it  makes 
reuse  easier.  We  believe  that  C2  is  such  a  style  for  GUI  soft¬ 
ware,  with  the  potential  for  broader  applicability. 

Several  characteristics  of  the  C2  style  have  enabled  it  to 
better  support  reuse  of  OTS  components  and  construction  of 
different  members  of  an  application  family  from  existing 
parts.  Although  most  of  these  characteristics  are  not  unique 
to  C2.  our  approach  of  combining  them  is.  We  believe  the 


style  rules  are  restrictive  enough  to  make  reuse  easier  wliile 
flexible  enough  to  integrate  components  built  outside  the 
style  and  connect  them  in  an  architecture  in  various  ways 
(“plug  and  play”): 

•  Component  heterogeneity  —  No  restrictions  are  placed  on 
the  implementation  language  or  granularity  of  the  compo¬ 
nents. 

•  Substrate  independence  —  A  component  does  not  depend 
on  the  existence  of  components  below  it. 

•  Internal  component  architecture  —  The  internal  architec¬ 
ture  of  a  C2  component  separates  communication  from 
processing.  The  dialog  isolates  the  internal  object  from 
changes  in  the  rest  of  the  architecture.  The  domain  trans¬ 
lator  reduces  the  dependence  of  a  component  on  compo¬ 
nents  above  it;  a  component  can  use  different  domain 
translators  in  different  architectures. 

•  Asynchronous  message  passing  via  connectors  —  Com¬ 
ponents  communicate  only  by  exchanging  asynchronous 
messages  through  connectors.  This  has  the  potential  to 
greatly  simplify  control  integration  issues,  such  as  those 
encountered  by  Garlan  and  colleagues  in  [9]. 10  Coupled 
with  partial  communication  and  sendee  utilization,  this 
property  also  facilitates  low-cost  interchangeability  of 
components  to  construct  different  members  of  the  same 
family. 

•  No  assumption  of  shared  address  space  —  Two  compo¬ 
nents  cannot  assume  that  they  will  execute  in  the  same 
address  space.  This  eliminates  complex  dependencies, 
such  as  components  sharing  global  variables,  and  simpli¬ 
fies  modification  of  architectures. 

•  No  assumption  of  single  thread  of  control  —  Conceptu¬ 
ally,  components  run  in  their  own  thread(s)  of  control. 
This  allows  components  with  potentially  different  thread¬ 
ing  models  to  be  integrated  into  a  single  application. 

•  Separation  of  architecture  f  ont  implementation  -  A  con¬ 
ceptual  C2  architecture  can  be  instantiated  in  a  number  of 
different  ways.  Many  potential  performance  issues  or 
variations  in  functionality  can  be  addressed  by  separating 
the  architecture  from  actual  implementation  techniques. 
We  have  found  that  wre  can  isolate  some  implementation 
decisions  in  the  C2  framew  ork,  discussed  in  Section  III. 
For  example,  a  connector  between  two  components  in  the 
same  address  space  can  use  direct  procedure  calls  to 
implement  message  passing. 

The  exercises  discussed  in  Sections  VI-Vin.  as  well  as 
recent  wrork  described  in  [20],  have  enabled  us  to  devise  an 
initial  set  of  heuristics  for  OTS  component  integration  in 
C2.  The  only  assumption  wre  make  is  that  OTS  components 
provide  application  programmable  interfaces  (APIs).  As  our 
experience  with  reusing  OTS  components  glows.  wre  expect 
that  this  fist  will  be  expanded  and  refined: 

•  If  the  OTS  component  does  not  contain  all  of  the  needed 
functionality,  its  source  code  must  be  altered  or  a  custom- 
built  component  must  be  supplied.  In  general,  this  is  a  dif¬ 
ficult  task,  whose  complexity  is  well  recognized  [9],  [13], 
[23]. 11 


10.  Wliile  the  style  does  not  forbid  synchronous  communication,  the 
responsibility  for  implementing  synchronous  message  passmg  resides  with 
individual  components 


•  If  the  OTS  component  does  not  communicate  via  mes¬ 
sages,  a  C2  wrapper  must  be  built  for  it.  This  was  the  case 
with  both  SkyBlue  and  Amulet. 

•  If  the  OTS  component  is  implemented  in  a  programming 
language  different  from  that  of  other  components  in  the 
architecture,  an  inter-process  (IPC)  connector  must  be 
employed  to  enable  their  communication.  A  number  of 
existing  systems  provide  this  capability.  For  example,  we 
were  able  to  accomplish  this  task  for  C++  and  Ada  com¬ 
ponents  relatively  easily  using  the  Q  software  bus  [16]. 

•  If  the  OTS  component  must  execute  in  its  own  thread  of 
control,  an  inter-thread  connector  must  be  employed.  This 
was  accomplished  in  the  case  of  the  Java  AWT  graphics 
toolkit. 

•  If  the  OTS  component  executes  in  its  own  process,  an  IPC 
connector  must  again  be  employed. 

•  If  the  OTS  component  communicates  via  messages,  but 
its  interface  does  not  match  interfaces  of  components  with 
which  it  is  to  communicate,  a  domain  translator  must  be 
built  for  it.  Although  we  have  done  some  preliminary 
work  on  domain  translation  in  our  Java  class  framework, 
this  area  needs  further  exploration. 

The  information  above  is  summarized  in  Table  7. 


Table  7:  OTS  Component  Integration  Heuristics  for  C2 


Problem  with  OTS  Component 

Integration  Method 

Inadequate  Functionality 

Source  Code  Modification 

No  Message-Based  Communication 

Wrapper 

Different  Programming  Language 

IPC  Connector 

Different  Thread  of  Control 

Inter-Thread  Connector 

Different  OS  Process 

IPC  Connector 

Message  Interface  Mismatch 

Domain  Translator 

The  series  of  exercises  described  in  this  paper  demon¬ 
strate  that  C2  isolates  changes  inside  components  and  limits 
any  global  effects  of  those  changes  through  message-based 
communication.  Furthermore,  C2’s  principles  of  substrate 
independence  and  domain  translation  enable  component 
substitutability.  Finally,  its  component-  and  message-based 
nature  allows  partial  communication  and  service  utilization 
of  components,  which  are  essential  to  cost-effective  reuse. 

In  a  component-based  style,  such  as  C2,  the  number  of 
possible  architectures  grows  combinatorially  as  the  number 
of  behaviorally  related  components  increases.  Thus,  the  18 
components  depicted  in  Table  1  can  generate  384  distinct 
versions  of  KLAX.  Of  course,  every  possible  architecture  is 
not  necessarily  meaningful  (e.g.,  the  example  of  partial 
communication  in  Section  VIII. B)  nor  particularly  interest¬ 
ing.  It  is  the  responsibility  of  the  architect  to  ensure  that 
each  constraint  is  properly  handled  somewhere  in  the  archi¬ 
tecture.  This  task  can  be  aided  by  a  design  guidance  tool, 
such  as  C2’s  Argo  design  environment  [30],  [31].  What  we 
have  shown  is  that  C2  gives  the  architect  added  flexibility  as 
to  exactly  where  and  how  to  include  the  constraint  handling 
behavior. 


1 1 .  Note  that  the  component  can  still  be  reused  “as  is”  if  the  developers  are 
willing  to  risk  degraded  or  incorrect  performance,  due  to  partial  communi¬ 
cation  and  partial  component  service  utilization  in  the  architecture.  This 
was  the  case  with  several  variations  of  KLAX,  discussed  in  Section  VIII. 


This  exercise  demonstrated  the  potential  for  creating  a 
library  of  components  and  an  application  family  in  the  C2 
style.  In  addition,  we  now  have  a  constraint  management 
component  in  the  C2  style  that  will  be  reused  across  future 
applications. 
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